Distribution of software, and specifically object code, for use in processing systems has been a problem since the beginning of stored program controlled systems. For example, in the area of telephone switching systems, stored program control has been used since the middle 1960's. In order to distribute a new operational programs (software) that operates these systems, initially a technician had to go to each switching office and physically remove magnetically encoded cards and install new magnetically encoded cards. As technology improved, magnetic tapes were used to transport programs from the point at which they are made to their point of utilization; in fact, magnetic tapes are still used for generic updates which currently involve large quantities (70-100 mega-bytes (MB)) of object code. All such systems required manual steps and high transportation costs for delivery of such software, especially as the size of the software loads grew over time.
Some recent systems rely on telephone data links for distribution of software. For example, the prior art system of FIG. 4 illustrates a typical software distribution system for various switching systems in a telephone network. Such switching systems could be local central office switches supported by a particular manufacturer, such as 5ESS.RTM. switches manufactured and supported by AT&T, or, alternatively, may be long distance-type switches such as the 4ESS.TM. switch, also manufactured and supported by AT&T. Other types of program-controlled systems may benefit from this invention without departing from the scope of the appended claims.
Each switch is connected to a software change and notification system (SCANS) 102. SCANS, as known in the art, provides software updates for switching systems 104-118 by way of data transmissions over lines 120-134 using dedicated point-to-point communication links operating at 9600 bits per second with an X.25 protocol.
FIG. 5 illustrates such a prior art SCANS-to-switching system connection. In the system of FIG. 5, SCANS 100 includes an application program 500, which processes the data to be sent (in the example of switching offices, the object code required). Application program 500 delivers the processed object code to a plurality of communications terminal processes 502-5NN, which communicate with the switching offices. In each communications terminal process 502-5NN, there is a send module 504 and a receive module 506. Send module sends the object code (again, for purposes of this example) over line 122 to switching system 104. Receive module 506 in terminal process 502 of SCANS 100 receives acknowledgement requests for re-tries, etc., as is known in the art, from switching module 104, via line 120.
At the switching system side, switching systems (in this example 102 and 104), also include a terminal process 508-508' which contain a send module 504 and a receive module 506 which are the same, or substantially similar, to the send 504 and receive processes 506 in the communications terminal process 502 of SCANS 100. Terminal process 508 in switching system 104 receives data in receive process 506 and delivers the received data to terminal process 508. Terminal process 508 determines whether data is received in tact, and if so, sends acknowledgements of good reception through send process 504 or re-try requests for data if the data appeared to be corrupted. Switching systems 104 and 102 are shown as having several layers that communicate with communications terminal process 508. First there is a SCANS interface 510 which performs protocol verification, etc. and other functions, as known in the art, with SCANS 100. If the data received appears correct, then SCANS interface 510 passes the received data to input/output process 512, which causes administrative module 514 to further distribute the received software (where the other processes reside). This hierarchy is very much like the system of FIG. 2.
In this manner, changes to the programs which run switching systems 102-118 may be made through a central location, for example, at a SCANS facility 100 outside of Chicago, and then sent to each switching system which requires the change. Furthermore, software updates, where entire sections of programs change, may also be sent to each switch 102-118 in this manner. Finally, an entire generic update (changing the entire operating code) may be sent from SCANS system 102, via lines 120-134, to all switching systems 102-118 which subscribe to or purchase the new generic. Therefore, the size of the data load being transmitted to each switch may vary from a few hundred bytes for a small bug fix to several hundred megabytes for an entire generic.
Turning now to FIG. 6, a prior art system is shown, wherein a switching office is connected to SCANS 100 by way of data line 120. Switching office 104 is, for example, a 5ESS switch, as manufactured by AT&T. As is known in the art, a 5ESS switch (local switch 104) may be a distributed control ISDN electronic telephone switching system such as the system disclosed in U. S. Pat. No. 4,592,048, issued to M. W. Beckner, et al. on May 27, 1986, and assigned to the assignee of this application. Alternatively, local switch 104 may be a digital switch such as a 5ESS switch manufactured by AT&T and described in the AT&T Technical Journal, Vol. 64, Number 6, July/August, 1995, pages 1303-1564.
The architecture of switch 104 includes a communication module 602 as a hub, with switching modules 604, 606, and 608 illustrated (there may be other switching modules but these are not shown for clarity) and an administrative module (AM) 610, emanating from communication module 602. Communication module 602 includes a time-shared, space division switch or time-multiplexed (TM) switch as a fabric for communications among switch modules 604, 606, 608, and between switch modules 604, 606 and 608 the AM 610. AM 610 provides coordination of the functional components of switch 104 and human-machine interface. Switch modules 604, 606, and 608 terminate analog and/or digital subscriber lines through line units (not shown but well-known in the art) and analog or digital trunk units (again, not shown but well known in the art) and communicate with CM 602 over control timeslot 611 (for sending control data) and other timeslots 613 (used for call processing). AM 610 also provides connections to other switching systems through, for example, a signaling system 612 (such as a common-channel-signaling network) by which the switching systems in a network communicate, and to SCANS 100 via connection 120.
In the current art, SCANS 100 sends data on line 120 at approximately 9600 baud. This data rate is adequate when SCANS 100 is sending small changes (or "patches") for code to switching office 104. However, when SCANS 100 is sending major updates or a generic update over line 120, this transmission may take many hours, depending on the size of the load or generic which is being sent to the administrative module 610.
The burden of distributing large software loads, particularly object code, at 9600 bps to AM 610 may slow down or delay other processing work of AM 610. For example, receiving an entire generic causes AM 610 to respond more slowly to signaling messages from signaling network 612 and for routing and administrative function requests from SMs 604-608 and CM 602. Therefore, it has been proposed that AM 610 be assisted by a work station, such as 614 (shown in phantom). Work station 614 is connected to SCANS 100 (instead of AM 610) and then communicates with AM 610 to build loads and otherwise direct AM 610 with the information delivered from SCANS 100. However, there is still a great deal of time involved delivering data from SCANS 100 to work station 614; work station 614 merely eases some of the processing burden on AM 610.
When the load is distributed to the various modules within switch 104, it takes resources and time away from other, more important (i.e., call processing) activities. After work station 614 or administration module AM 610 finish processing the new generic (or other update), then the operational code or other data must be delivered to its final destination module.
AM 610 communicates with communication module 602 over a standard bus connection, as is known in the art. Communication module 602 communicates with each of the switch modules 604, 606, and 608, via a plurality of timeslots. There are types of timeslots, control timeslots 611 and timeslots 613. Timeslots 613 are used for communication purposes, such as telephone calls, data calls, etc. Timeslots 611 are used to control the switch modules themselves. When there is an operating system update of any size, control timeslots 611 are used for transporting the data from communication module 602 to each of the switch modules 604, 606, and 608. Thus, it may take a long time (from minutes to hours) in order to migrate all of the code necessary to replace an entire generic in a switch module.
Therefore, a problem in the art is that there is no method for delivering data at a high rate of speed to multiple units in a distributed processing system simultaneously, while still maintaining reliability of applications processing.